home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 3.8 KB | 79 lines | [TEXT/GEOL] |
- Item 3813640 14-Dec-90 00:35PST
-
- From: MUYSVASOVIC ACE - Jean-Denis Muys-Vasovic
-
- To: INTELITOOL Intelitool, Alan F Holmquist,PRT
-
- cc: MACAPP.TECH$ MacApp Technical
-
- ------------------------------------------------------------------------------
-
- Sub: Re: MacApp vs. AppMaker
-
- Chuck,
-
- In fact, you cannot compare, MPW C/Pascal, MacApp, and Appmaker against one
- another. They are quite different tools, which have all a place in the
- development process. Let me elaborate a bit.
-
- To do any development, you'll need at least the three following components:
-
- 1- Development tools, including a development environment (eg MPW, Think), and
- utilities which might be more or less necessary (eg ResEdit, AppMaker,
- ViewEdit, MacBrows…).
-
- 2- A language (eg C++, Object Pascal, Lisp, COBOL).
-
- 3- A code library (eg the Mac Toolbox, MacApp…).
-
- MacApp was written by Apple to work with MPW. For another environment to be
- compatible with MacApp, it must satisfies either one of two conditions: a-
- source level compatibility. Since MacApp was written in Object Pascal, it must
- then support Object Pascal. Example: Think pascal. or b- object level
- compatibility. Here that means it must be able to import MPW .o files, and also
- respect the Pascal calling conventions. Weak example: p1 Modula II.
- Specifically, Think C doesn't satisfy as of today either of the two conditions.
- Therefore the answer to your question is no. It now belongs to Symantec to take
- action. This is a more general problem with Think environment: they are
- mono-language. You should be able to write an application party in Think
- Pascal, partly in Think C.
-
- AppMaker could be classified in the broad category (who said class?) of CASE
- tools. It is supposed to solve a general problem: I want to draw my user
- interface on the screen, and not the code to generate it. Both MacApp and
- AppMaker have an answer to that problem, but they are very different in nature.
-
- AppMaker chose to generate source code. The advantage of this approach is
- generality. You can easily tie a menu item with a dialog for example. You can
- generate the glue code with the "real" stuff. The disadvantage is lack of
- maintainability and localizability: quite often, you can't redesign your user
- interface, even the slightest detail, as soon as you've started adding your
- code to the generated code. I learned that the latest version of Prototyper,
- the competitor of AppMaker, has solved this problem. I haven't seen it yet, but
- I suspect there are some unpleasant constraint to achieve that. Any report
- appreciated.
-
- MacApp chose the resource approach. The interface is specified in resources (eg
- 'cmnu' and 'view'). The resources are then read in at run time by the code
- library, and the specification followed. The disadvantage of this is that you
- lose completeness: you must write the glue code to call on the library and to
- link the user interface elements together. Also, the supporting code is more
- complex, since it belongs to the library, instead of the utility (AppMaker).
- One advantage of that is localizability, because you don't have to recompile
- your application to change the specification. Another is maintainability,
- because the supporting code is not part of your source code. If a bug is
- discovered, or if a feature is enhanced, you just have to relink with the new
- version of the library (well, to a certain extent).
-
- A good try would be to combine both approches, eg use AppMaker to generate the
- glue code which will call MacApp code. This possibility will soon be offered by
- AppMaker. See also MacApp drafter on ETO.
-
- In the current state, AppMaker is not compatible with MacApp. This disqualifies
- AppMaker for most serious development.
-
- I hope I clarified things a bit.
-
- Jean-Denis
-
-